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ABSTRACT 


This research, conducted at the request of the United States Coast Guard Manpower 
Requirements Determination Division, determines the data requirements for partial 
automation of the manpower requirements determination process. The Division currently 
uses a manual process to determine manpower requirements; however, the research 
proposes that many of the tasks can be partially automated to provide greater efficiency 
as well as capability. To accomplish this goal, the factors that contribute to determining 
manpower requirements are modeled in an entity-relationship diagram, and subsequently 
implemented in a relational database. These efforts confirmed that implementing a 
Manpower Requirements Determination Automated Information System would create 
greater efficiency in the United States Coast Guard’s manpower requirements 
determination process. Additionally, due to the relative sameness of the United States 
Coast Guard and the United States Navy, the research recommends a continued 
relationship between the United States Coast Guard’s Manpower Requirements 
Determination Division and the United States Navy’s Manpower Analysis Center in 
support of future adaptation in regard to manpower requirements determination. 
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I. 


INTRODUCTION 


A. BACKGROUND 

The United States Coast Guard (USCG) faces a challenge getting the right people, 
in the right places, at the right times. According to the Government Accountability 
Office, this challenge was compounded when the USCG transitioned from the 
Department of Transportation to the Department of Homeland Security (DHS) in 2003, 
and subsequently as its role in homeland security expanded (United States General 
Accounting Office, 2003). Currently, the USCG is charged with the execution of 11 
missions including ports, waterways, and coastal security; drug interdiction, aids to 
navigation, search and rescue, living marine resources, marine safety, defense readiness, 
migrant interdiction, marine environmental protection, ice operations, and other law 
enforcement. As such, the USCG is required to be agile and responsive to changing threat 
conditions in many different operating environments. 

Determining manpower requirements and getting the right people, in the right 
place, at the right time, is an ongoing and complex process. The focal point is to identify 
the optimal number of people with the right knowledge, skills, and abilities. Too few or 
underqualified people may adversely impact safety, readiness, and mission execution. 
Too many or overqualified people may siphon funding from other priorities. Currently, 

the USCG lacks a system-wide methodology, an integrated set of 
applications, and common data warehouses needed to fully develop an 
effective and efficient manpower requirements engineering and 
management program. The lack of an objective control mechanism for 
determining the right number and skill mix of manpower creates 
inefficiencies in the ability to provide the right manpower to effectively 
meet the workload demands of our organization. (Papp, 2006, p. 1). 

In May 2006, Admiral Thad W. Allen became the 23rd Commandant of the Coast 
Guard. The Admiral’s goal for his tenure was to improve mission execution. He 
communicated his vision to the organization via Commandant Intent Action Orders 
(CIAO). Order number 8, “Human Resource Strategies to Support USCG Maritime 
Strategy,” was published in August 2006. This order called for a process to ensure “the 
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right mix of human capital to support mission execution” (Allen, 2006, p. 1). Two 
specific initiatives outlined in the CIAO were “to establish methods to use measured 
workload data to define human capital requirements,” and to “design and begin 
implementation of an automated information system that will allow individuals, unit 
commanders, and program managers to compare competencies held with competencies 
required by specific jobs or types of jobs for the purpose of defining the gaps” (Allen, 

2006, p. 2). 

CIAO 8 was directed to Human Resources, CG-1. In October 2006, the Human 
Resource Strategy and Capability Development Office, CG-1B, responded by 
establishing the Manpower Requirements Determination (MRD) Enterprise Development 
Team. “The principal goal of creating an MRD enterprise is to increase our ability to 
account for resources within the Coast Guard...” (Papp, 2006, p. 1). One of the MRD 
Enterprise Development Team’s tasks was to “develop [a] centralized, web-enabled 
MRD data repository to capture work measurement data” (Papp, 2006, p. 6). In October 
2008, the expectations of the MRD Enterprise Development Team were updated to 
include more specifically the development of a Manpower Requirements Determination 
Automated Information System (MRD AIS) and the creation of a temporary MRD 
database to house extant and future data (Breckenridge, 2008, p. 4). 

The construction of a MRD AIS exceeded the capabilities of USCG employees so 
the service contracted an information technology company to build the system. “The 
primary goal of the MRD AIS project is to create a verifiable, repeatable, and defendable 
program that collects, measures, and analyzes the human capital needed to perform Coast 
Guard missions” (Commandant (CG-1B1), 2008a, p. 8). More specifically, the project’s 
business objectives (BO) called for the system to: 

• Reduce the process cycle time associated with workload demand 
evaluation, manpower requirements determination, and labor 
consumption measurement; 

• Develop a standard process for determining the manpower 
requirements necessary to meet mission objectives; 
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• Increase the quality of work products associated with human 
capital decision support; and, 

• Improve visibility of the USCG workforce, human resource 
demand, demand consumption, and demand cost information 
(Commandant (CG-1B1), 2008b, p. 14). 

Also, the MRD AIS was to have three primary components: 

• A central repository to house workload data; 

• An optimization mechanism to determine the right amount and mix 
of manpower within an organization structure; and, 

• A modeling and simulation process to generate alternatives to 
support the best business case for each alternative (Commandant 
(CG-1B1), 2008b, p. 17). 

To date, the contractor-built MRD AIS nor any other MRD AIS has been 
integrated into USCG Manpower Requirements Analysis. No formal documentation 
exists as to why the MRD AIS was never adopted. Informal communication with the 
USCG Manpower Requirements Determination Division suggest that difficult interface, 
incomplete identification of factors that determine manpower requirements, and non¬ 
standard terminology have prevented the system from being integrated into Division 
operations. 

Since the delivered MRD AIS is not being used, the USCG is continuing to use an 
antiquated and laborious process to determine manpower requirements. The process 
involves spreadsheets and manual calculations. These tasks can be easily completed and 
synthesized by a database which would translate to substantial time-savings and 
efficiency. Therefore, developing a robust MRD AIS remains a priority. 

The development of a MRD AIS also has benefits beyond time-savings. For 
example, it would improve the standardization of manpower requirements across the 
service. It would alleviate resource managers from being influenced by local or 
programmatic needs, and eliminate similar unit types and requirements from being 
manned differently. Next, a MRD AIS would increase the transparency of manpower 
requirements at all levels and positively contribute to decision making. Specifically 
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increased visibility would not only inform staffing standards but recruiting, training, and 
advancement initiatives as well. 

B. PURPOSE 

The purpose of this study is to demonstrate the potential value in implementing a 
MRD AIS in the USCG. More specifically, the objective is to model the factors that 
contribute to determining manpower requirements in an entity-relationship diagram 
(ERD), and subsequently test the model using a relational database. The intent of a MRD 
AIS is to improve the accuracy of determining manpower requirements, alleviate time 
intensive manual processes, standardize manpower analysis across the USCG, increase 
transparency, bolster the service’s ability to adapt to changing conditions, optimize 
manpower allocation, and identify alternative staffing solutions. Ultimately, the purpose 
of the study is to contribute to improved efficiency within CG-1B. 

C. SCOPE AND METHODOUOGY 

This project includes a literature review, an ERD, and a relational database for 
test and evaluation. The literature review is limited to a presentation and comparison of 
USCG and Navy processes for determining Fleet and shore manpower requirements. The 
comparison is made between the USCG and the Navy due to the similar nature of their 
mission requirements and aggregate resources for which requirements are determined. 
Industry, Air Force, Army, and Marine Corp processes are not reviewed. An ERD will be 
constructed; it will model USCG entities and attributes that contribute to determining 
manpower requirements. The model is original and not an extension of any contractor’s 
work. A relational database will be built, and tested with simulated data. The primary 
method of testing the model and relational database will be via queries. The testing will 
be considered successful when a query produces a spreadsheet or table similar to 
products found in MRA Reports. No code was executed to perform mathematical 
computations or to yield summary information. 


4 



D. ORGANIZATION OF STUDY 


This study is comprised of four chapters that include: Introduction, Overview of 
MRD, Description of Method and Analysis; and Summary, Conclusions, and 
Recommendations. Chapter II is the Overview of MRD; it is the literature review. 
Chapter III is the Description of Method and Analysis. It presents and explains the ERD 
and relational database. Simulated data is used to test the relational database, and the 
results are described. Chapter IV is the Summary, Conclusions, and Recommendations. 
This chapter is a compellation of the study’s findings, and prescribes what may also be 
done to advance the implementation of an MRD AIS in the USCG. 


5 



THIS PAGE INTENTIONALLY LEFT BLANK 


6 



II. MRD OVERVIEW 


This chapter summarizes the United States Coast Guard (USCG) and Navy 
processes for determining fleet and shore manpower requirements, and identifies 
similarities and differences between the processes. The literature reviewed is 
predominantly USCG and Navy publications. Note: the USCG Staffing Logic and 
Manpower Requirements Manuals, Volumes II through IV, which are reviewed as part of 
this project, are in draft form at this writing and may be subject to change prior to 
publication. 

Proximity to Navy manpower subject matter experts, the similarity between the 
USCG and the Navy, and the presence of USCG members at the Navy Manpower 
Analysis Center (NAVMAC) motivated me to compare the USCG Manpower 
Requirements Determination (MRD) process with the Navy MRD process, as oppose to 
the process of another service. Further, the Navy process influenced the USCG process, 
so there is benefit to understanding the similarities and differences. 

Regardless of the service, the focal point of manpower requirements 
determination is to get the right people, to the right places, at the right times, with the 
right skills. Accurate manpower requirements determination ensures a ready force, and 
safe and effective mission execution. Shortage or excess of manpower is the catalyst to 
compromised mission execution or waste, respectively. 

A. USCG MRD 

The name of the Coast Guard’s process for determining manpower is the 
“Manpower Requirements Process”; it has three components. They are the Manpower 
Requirements Analysis (MRA) Process, the MRD, and the Capabilities Reconciliation 
Process (CRP). The MRA Process has three phases, Phase I, II, and III: Requestor 
Alignment, Mission Alignment, and HR System Alignment, respectively. The MRD is a 
product of the MRA Process. The CRP also has three phases, Phase IV, V, and VI: 
Program Alignment, Resource Alignment, and Establishment of Manpower Standards 
respectively. The Manpower Requirements Process, its components and phases are 
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shown in Figure 1. The focal point of this project, however, is the MRA process, which is 
described at length in the following paragraphs. 


Manpower 
Requirements 
Process 


MRA Process 

Phase 1 
Phase 2 
Phase 3 


MRD 


CRP 


Phase 4 


c 


Phase 5 


Phase 6 


D 

D 


Figure 1. USCG Manpower Requirements Process. 


1. MRA Levels 

There are four levels of MRAs; listed in order of increasing analytical rigor, they 
are: 

• MRA Level 1-Manpower Estimate Report (MER) 

• MRA Level 2-Workload Consolidation 

• MRA Level 3-Workload Validation 

• MRA Level 4-Workload Observation. 

The MRA Level is determined before the MRA begins. The MRA level is determined by 
a number of things including but not limited to the purpose of completing the MRA, the 
time available, the program requirement, and the OE’s complexity. Regardless of the 
MRA Level, Phases 1-3 are completed for each MRA. 

Although included as part of the hierarchy of MRAs completed in the USCG, a 
MRA Level 1-MER does not meet the analytical rigor of a true MRA. An MRA Level 1 
is conducted when undefined mission requirements exist, for example, as a result of a 
system acquisition. An MRA Level 1, however, is key documentation for a subsequent 
MRA Level 2, 3, or 4 after mission requirements are determined and there exists basehne 
workload data. 
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As the degree of analytical rigor increases so does the level of intrusiveness into 
the organizational element (OE), a unit or a portion of a unit. MRA Level 2 is almost 
exclusively, and MRA Levels 3 and 4 begin with, a thorough review of policy documents 
and related resources. MRA Levels 3 and 4 use surveys and interviews of subject matter 
experts to validate work and collect workload data. In MRA Level 4, the MRA analyst 
visits the OE to observe directly the work and to collect workload data. 

2. Before the MRA Process Can Begin 

An MRA for fleet or shore OEs is initiated via an MRA request to the Manpower 
Requirements Determination Division, CG-1B4. The person, office, or command that 
files the MRA request is the “requestor.” The MRA request is evaluated to determine 
what type of analysis will meet the needs of the OE for whom the MRA request was 
submitted. Once a mutual decision is made in regard to the best analysis method, the 
MRA request is added to the MRA Prioritization List managed by CG-1B4. 

CG-1B4 does not have enough resources to complete every MRA request, nor the 
resources to complete the MRAs they commit to without contractor support. Whether an 
MRA is completed by organic or contracted resources depends on available funding, 
MRA priority, OE size and type, timeline, etc. 

The final actions before Phase 1 begins are assignments of MRA personnel, and 
the completion of the Performance Work Statement (PWS). Once it is decided that a 
particular MRA will be completed, a team will be assigned if the MRA is to be 
completed with organic resources, or a team leader will be assigned to act as a project 
manager if the MRA is to be completed with contracted resources. Regardless, if organic 
or contracted resources are completing the MRA, a PWS is completed. A PWS is 
essentially a contract, describing what products and services will be delivered. When a 
contractor is completing the MRA, the PWS is fiscally binding and guides the MRA 
throughout the entire process. 
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3. Phase I-Requestor Alignment 

Phase I, Requestor Alignment, is simple. It begins with the Alignment Meeting 
and concludes upon the submission of the Alignment Report. The Alignment Meeting is 
the forum where OE representatives meet with the respective CG-1B4 Analysis Team 
and exchange expectations. At a minimum, goals, objectives, and timeline are discussed. 
The required Alignment Report captures relevant project information and concludes 
Phase I. 

4. Phase II-Mission Alignment 

Phase II, Mission Alignment, is much more involved than Phase I. Phase II 
includes the identification and measurement of work, the recognition of assumptions and 
constraints, and the application of allowances. To help clarify the process, Phase II has 
guiding principles and core assumptions that direct the Phase. 

Three of the four guiding principles are particularly notable and set the tone for 
the MRA. The first is that “The MRA process shall be free of political, budget, strategic, 
or mission prioritization constraints...” (Commandant, 2014, p. 3.F.3.a). The MRA 
should figuratively be executed in a vacuum as if only the work exists, and the analyst is 
determining for the first time what manpower is required. 

The second notable guiding principle is “MRD analysts shall identify and 
categorize all work associated with the OE... but shall only analyze the OE’s adjudicated 
work requirements” (Commandant, 2014, p. 3.F.3.a). Work requirements that are not 
adjudicated are not directed by extant data resources, organizational directives or 
publications. An example of work that may not be adjudicated is an extra daily safety 
patrol executed by a USCG station. This patrol is not a requirement, and is above and 
beyond what is expected of the station. In this example, it also surpasses what can 
routinely be executed by a single watch section, so the Commanding Officer directs an 
additional boat crew to be added to each watch section. This increased patrol posture 
again is not a requirement so will not be identified as work during an analysis. Therefore, 
the USCG station will not receive additional manpower to execute the additional daily 
safety patrol. OE leadership should be careful not to obligate itself to work that cannot be 
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adjudicated as additional manpower will not be provided to facilitate the completion of 
these tasks. 

The third notable guiding principle is “MRD analysts shall identify an audit trail 
that can be easily traced,” and the “MRD will reflect the minimum manpower, minimum 
pay grade, and competency requirements necessary to perform the work” (Commandant, 
2014, p. 3.F.3.a). This principle alleviates bias by directing a process with a clear 
standard that yields results that are verifiable, repeatable, and defensible. 

Guiding principles and core assumptions in place, Phase II begins with the Data 
Collection Plan (DCP). It is a tool to organize the data collection, and help set the sponsor 
and OE’s expectations. The DCP includes the type of information to be collected, the 
method(s) used to collect the information, the personnel required to support the 
information collection, and the associated logistics. Information collection methods 
include work sampling, operational audit, interview, and survey. “The DCP is made up of 
a series of tables that list interview subjects, extant data sources, electronic data sources, 
and other sources of information particular to the OE being studied” (Commandant, 
2010a, p. 3-2). 

The Work Matrix, also a series of spreadsheets, is the data repository for collected 
work and workload information during an MRA. It contains a significant amount of 
information about each task including task description, type, class, reference, frequency, 
count, etc. The Work Matrix is the foundation for future analysis including modeling and 
options development. Work and workload can alternatively be recorded in an Operational 
Audit or in Task Lists. 

Once the MRA team identifies work and workload, their findings are adjudicated 
during the Work Adjudication Conference (WAC). This “is an iterative back-and-fourth 
discussion between the requestor and MRA team” (Commandant, 2014, p. 3.F.3.C.4.). 
Gaining concurrence in regard to the information recorded in the Work Matrix, and 
subsequently agreeing on the assignment of competencies and major accomplishments to 
tasks are focal points of the WAC. Results from the WAC are documented in a Work 
Report that capture the requestor’s, the OE’s, and the MRA team’s collaborative efforts. 
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Workload constraints and assumptions (WCA) must also be accounted for when 
identifying work and workload information. Assumptions and constraints influence how 
work is identified, measured, and distributed. For example, a constraint may dictate a 
specific rank to whom a particular task should be distributed. The product that captures 
workload constraints and assumptions as well as total workload requirements is the WCA 
Report. It is submitted during Phase II as a follow-up to the Work Report, but the 
information is not applied until Phase III. 

Phase II ends with the application of allowances. Allowances account for time 
members are at work but not accomplishing their specific workload. Allowances that may 
be applied are Personal Fatigue and Delay (PF&D), Training, Make Ready/Put Away, 
and Corrective Maintenance Ratio (Commandant, 2014, p. 3.F.3.C.6.). For example, these 
allowances account for a member’s personal needs, training, information requirements, 
and preparation and clean up before and after maintenance, etc. Allowances positively 
contribute to the accuracy of determining manpower requirements. They alleviate 
distributing more work, than what can reasonably be achieved, to any one position. 

5. Phase Ill-Human Resources System Alignment 

Phase III, Human Resources (HR) System Alignment, is centered on modeling the 
information collected in the previous phases and yielding alternative staffing options. 
Phase III also includes an MRA Options Report, an MRA Manpower Option Selection 
Meeting, and an MRA Report. The publication of the MRA Report ends Phase III and the 
MRA. 

Until Phase III the requirements determination process for fleet and shore is the 
same. The process diverges at modeling. Fleet requirements are determined by the Navy 
Manpower Requirements System (NMRS), and shore requirements are determined using 
the Manpower Determinant Model (MDM). NMRS “utilities a ‘building block’ process 
wherein the categories of workload and watchstanding requirements are accumulated and 
processed to form the minimum billet requirements” (Commandant, 2014, p. 3.F.4.b.). 
“The MDM captures all work, organizes tasks by major accomplishment, calculates 
workload, and distributes work based on the minimum pay grade necessary to complete 
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the work” (Commandant, 2014, p. 3.F.4.a.). Despite the different modeling methods, a 
common business rule is that manpower is determine to a minimum. 

Results of the modeling, namely alternative staffing options, are documented 
within an MRA Options Report. The MRA Options Report not only details alternative 
staffing options, but also provides analysis in regard to capability and capacity limitations 
and requirements. Before the MRA team makes the MRA Options Report available to the 
requestor, it is submitted to MRD partners and stakeholders to confirm the viability of 
each staffing option. Following partner and stakeholder review, the MRA Options Report 
is made available to the requestor. 

The MRA Options Report is discussed at length at the Manpower Option 
Selection Meeting. This meeting is the requestor’s opportunity to discuss the different 
staffing options with the MRA team, ask questions, and identify discrepancies. Most 
notable at this meeting, the requestor selects its preferred staffing alternative, and it is this 
choice or MRD that is captured in the MRA Report. Upon submission of the MRA 
Report, Phase III and the MRA process are complete. 

Although the MRA process is not complicated, it is lengthy and requires several 
meetings and reports. The MRA Phases, required meetings and reports are summarized in 
Figure 2. 
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Figure 2. MRA Phases, required meetings and reports. 


B. NAVY MRD 

The Navy determines four types of manpower requirements: Fleet, shore, 
Individuals Account (IA), and Outside Navy. Only Fleet and shore requirements will be 
reviewed in this research. Regardless of the type of manpower requirement, the definition 
is the same: 

Manpower requirements define the number of personnel required to 
perform the Navy’s work and deliver the specified capability. Each 
manpower requirement equates to a specific manpower space which is 
assigned qualifiers that define the duties, tasks, and functions to be 
performed and the specific skills and skill level required to perform the 
delineated functions. (Office of the Chief of Naval Operations, 2007, 

P- 1-D 

Despite the type of requirement, Navy manpower requirements reflect the 
minimum quantity and quality of work by occupation to meet mission requirements. 
“These two factors are commonly paired together as ‘quan/qual’” (Office of the Chief of 
Naval Operations, 2007, p. 2-2). Quantity is the number of manpower requirements to 
meet mission requirements. It is calculated using Navy Standard Work Weeks. Quality is 
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the occupational knowledge, skills and abilities that are required to execute mission 
requirements. The parameters for quality are found in the Navy Enlisted Occupational 
Classification System (NEOCS) described in the Navy Military Personnel Manual 
18068F, and the Navy Officer Occupational Classification System (NOOCS) described in 
the Navy Military Personnel Manual 158391. 

1. Fleet Requirements 

Fleet manpower includes requirements for ships, squadrons and other deployable 
units. Required Operational Capability/Projected Operating Environment (ROC/POE) is 
the principal resource that directs mission requirements that translate to work and 
subsequently manpower requirements. Some of the other sources that influence Fleet 
manpower requirements are Navy Training Systems Plans and Activity Manpower 
Document (AMD) Change Requests. 

The determination of all Fleet manpower requirements is centralized at 
NAVMAC. NAVMAC (N121) is overseen by OPNAV N12, the Total Force 
Requirements Division. Teams from NAVMAC visit units to collect, assess, and validate 
workload. Fleet workload is dominated by watch standing. Workload information, 
specifically workload hours, are inputted into the Navy Manpower Requirements 
Systems, and paired with occupational knowledge, skills, and abilities to further quantify 
and qualify manpower requirements. NMRS produces a recommended manpower mix 
based on the determined and validated workload information. Next, workload and 
manpower information is entered into the Total Force Manpower Management System 
(TFMMS). TFMMS is a data repository, and “the single, authoritative database for Total 
Force manpower requirements, and active duty MPN/RPN [Military Personnel 
Navy/Reserve Personnel Navy] manpower authorizations and end strength” (Office of the 
Chief of Naval Operations, 2007, p. B-18). 

The Fleet Manpower Requirements Determination Process yields one of three 
documents at the conclusion of the process. The type of document produced depends on 
the unit evaluated. The potential documents are: the Fleet Manpower Document (FMD), 
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the Squadron Manpower Document (SQMD), or the Ship Manpower Document (SMD). 
These documents capture fleet manpower requirements by unit class. 

Once programmed funding is applied to Fleet Manpower Requirements an AMD 
is produced. An AMD is “the qualitative and quantitative expression of manpower 
requirements (military, civilian, and contractor) and authorizations (military) allocated to 
a naval activity to perform the assigned MFTs [Missions, Functions, and Tasks] or 
ROC/POE” (Navy Manpower Analysis Center, 2000, p. M-l). As the definition suggests, 
this document differs from the FMD, SQMD, and SMD in that it captures manpower 
requirements and authorizations. The AMD reports manpower requirements by Unit 
Identification Code (UIC) and notates their funded or unfunded status. The Fleet 
Manpower Requirements Determination Process is summarized in Figure 3. 
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Figure 3. Navy Fleet Manpower Requirements (from Hatch, 2013). 
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2. Shore Requirements 

Shore manpower requirements include activities that are not governed by 
ROC/POE, and are not IA or Outside Navy requirements. “Navy shore manpower 
requirements shall be based on directed Missions, Functions, and Tasks (MFTs)” (Office 
of the Chief of Naval Operations, 2007, p. 2-2). Shore manpower requirements are also 
influenced by AMD Change Requests and PWSs. 

The Shore Manpower Requirements Determination Process (SMRDP) is 
decentralized. 34 individual Budget Submitting Offices (BSO) determine manpower 
requirements for their respective constituency. BSOs are made up of military, civilian, 
and contract personnel. 

As a result of the decentralization of the SMRDP from BSO to BSO the process is 
not standardized. Similar to NAVMAC’s analysts, BSO personnel visit various units to 
collect, assess, and validate workload, however, workload measurement methods vary. 
Two popular methods are Op Audit and Work Sampling, which are based in statistics. 
“Op Audit is a work measurement tool in where work-hours required to accomplish 
defined categories, tasks, and subtasks of work within a work center/organizational 
component are derived by identification and summation of frequencies of occurrence 
multiplied by their unit times” (Navy Manpower Analysis Center, 2000, p. 5-1). Work 
sampling is based on the notion that random samples from a large population will reflect 
the characteristics of not only the sample but the population. 

Regardless of the workload measurement method used, results are inputted into 
TFMMS. Since BSOs are decentralized and TFMMS is the repository for significant data 
that informs resource decisions, not all BSOs have the direct capability to change 
TFMMS. Instead they have access to the TFFMS Micro Manpower Change Application 
(TMMCA) which feeds TFFMS. 

The Shore Manpower Requirements Determination Process yields a Statement of 
Manpower Requirements (SMR) during peacetime and a Mobilization Statement of 
Manpower Requirements (MSMR) for wartime. 
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In general terms, the analyst develops the SMR/MSMR by calculating 
quantitative and qualitative manpower requirements based on work 
measurement and methods improvement data. The SMR/MSMR will 
reflect the skill and manpower mix requirements needed to support the 
activity’s directed MFTs and associated workload. (Navy Manpower 
Analysis Center, 2000, p. 1-5) 

The SMR and the MSMR reflect requirements only. The AMD follows the associated 
SMR and the MSMR. Similar to the Fleet Manpower Requirements Determination 
Process, the AMD reflects requirements and authorizations. The SMRDP is summarized 
in Figure 4. 


SHORE MANPOWER REQUIREMENTS 


Input Throughput Results 

Outputs 



Figure 4. Navy Shore Manpower Requirements (from Hatch, 2013). 


C. CHAPTER SUMMARY 

The USCG and Navy share the objective to get the right people, to the right 
places, at the right times, with the right skills. Accurate manpower requirements reflect 
the standard for a ready force, and safe and effective mission execution. In both services 
mission requirements drive manpower requirements, and manpower requirements are 
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determined to a minimum quantity, to minimum pay grades, and to minimum 
competencies. 

The USCG and Navy processes for determining manpower requirements are also 
similar. In fact, the USCG has adopted many Navy processes as its own. For example, the 
USCG uses NMRS to model Fleet Manpower Requirements. The USCG is able to use 
Navy products because the nature of work between the services is comparable. 

As similar as the USCG and Navy processes for determining manpower 
requirements are some fundamental differences exist. For example, the Manpower 
Requirements Determination Division, CG-1B4 is the authority for Fleet and shore 
USCG MRDs, whereas the Navy’s organization is significantly decentralized. NAVMAC 
is the authority for Fleet manpower requirements, and 34 individual BSOs are the 
authorities for shore manpower requirements. 

Meeting twenty-first century challenges start with accurate manpower 
requirements determination. There is benefit to the USCG and the Navy remaining 
appraised of each service’s best practices and lessons learned. Exchange between the 
services will contribute to optimizing their respective manpower requirements 
determination processes. 
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III. DESCRIPTION OF METHOD AND ANALYSIS 


The United States Coast Guard (USCG) either completes Manpower 
Requirements Analyses (MRA) organically with Active Duty and civilian members using 
a series of spreadsheets, or contracts them out. This is inefficient, because it is costly, 
untimely, lacking transparency and standardization, etc. The vision to improve the 
Manpower Requirements Process includes a new or revised Manpower Requirement 
Determination Automated Information System (MRD AIS) with data repository, 
optimization, and modeling and simulation capabilities. 

The foundation of a MRD AIS and many process automation systems is an entity- 
relationship diagram (ERD) and a subsequent relational database. The relational database 
is the data repository, however, queries can be run within the relational database that 
produce tables similar to tables found in MRAs. The query capability is a source of 
efficiency, and will alleviate Manpower Requirements Determination (MRD) team 
members from manually drafting these tables. 

The scope of this project includes the ERD, a relational database, and the 
verification and validation of the ERD via testing the relational database. A description of 
these products are found in the following paragraphs. Overall, this project demonstrates 
fundamentally the efficiency that may be gained by implementing this or a similar 
relational database. 

A. MODELED FACTORS THAT CONTRIBUTE TO DETERMINING 

MANPOWER REQUIREMENTS 

Accurate manpower requirements determination relies on the thorough 
identification and consideration of the factors that influence manpower requirements. For 
example, although members are at work for approximately 8-12 hours, they do not 
complete 8-12 hours’ worth of work. Aside from at least one break for a meal during that 
time, members need breaks to mitigate fatigue, use the bathroom, etc. Therefore, it is 
important to determine how much time members actually spend working while they are 
at work. Time away from work as a result of dental and medical appointments, drills, 
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physical fitness, training, etc., also need to be considered. If these interruptions are not 
accounted for with “allowances,” an entity in the ERD, more work will get distributed to 
a member than what he or she can actually complete. This example illustrates that failing 
to be thorough and specific in identifying factors that contribute to determining 
manpower requirements could significantly skew an MRD, and underestimate the 
quantity of members required to complete a prescribed amount of work or mission. 

Incomplete identification of factors that influence manpower requirements not 
only impact the quantity of members determined but the quality of members determined 
as well. As described in the Navy MRD section, this is quan/qual, also known as “fill and 
fit.” Quantity is synonymous for fill, and quality is synonymous for fit. An example for 
fit is the consideration of competencies. If a small boat station has boats with outboard 
engines, and the only assigned Machinery Technicians assigned have not been to the 
outboard engine school and only have experience with inboard engines, this degrades the 
unit’s assets’ operational availability and ultimately the unit’s overall readiness. 

Thorough identification of factors that influence the quantity and quality of 
manpower is imperative to accurate MRAs and MRDs. To be as thorough as possible in 
determining these factors, the USCG Staffing Logic and Manpower Requirements 
(SLMR) Manuals, Volumes I-IV; associated job aids and templates, and recent MRAs 
for the following organizational elements: Judge Advocate General (JAG) Program, 
Maritime Force Protection Unit (MFPU), Regional Dive Locker Pacific, and WTGB 140’ 
(Bay) Class Icebreaking Harbor Tug were reviewed. 

To help identify the factors that influence manpower requirements, nouns that 
describe people, work or workload, and organization were the focal point. In regard to 
people, nouns and adjectives including but not limited to competency, position, rank, 
rate, and work week availability were brainstormed. For work; allowances, assumptions, 
constraints, major accomplishments, and tasks were compiled. For organization; 
department, division, section, and team was recorded. A complete list of factors can be 
found in Appendix A. 
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A significant challenge in identifying the factors that contribute to determining 
manpower requirements was non-standard terminology. Language in the MRAs deviated 
from the language used in the SLMR Manuals (note: Volumes II-IV were in draft form), 
and further language in the MRAs deviated from one another. Therefore, it was difficult 
to determine what factors were synonymous with one another, and what factors were 
different enough that they should have a unique entity or attribute. A catalyst of the non¬ 
standard terminology may be that different sources, two different contractors or the 
USCG, which completed the reviewed MRAs. 

A particularly interesting example of non-standard terminology is the use of 
“task” and “work item,” as well as “category” and “major accomplishment.” The impetus 
for the USCG to group tasks into major accomplishments was derived from the Navy 
Total Force Manpower Requirements Handbook (Commandant, 2014). The handbook, 
however, uses the term “category” while the USCG uses “major accomplishment.” Based 
on informal communications with the USCG MRD Division, the USCG uses major 
accomplishment to standardize its language with USCG Human Performance Technology 
(HPT) divisions that use terminology consistent with the Accomplishment Based 
Curriculum Development (ABCD) system founded by Joe Harless. That said, it appears 
standardization with HPT divisions stopped short, because the USCG is using work item 
vice task. This is contradictory as task is consistent, and work item is not consistent with 
the ABCD system. Further exacerbating the issue is that category and major 
accomplishment are sometimes used synonymously, and sometimes category is used in 
other contexts. Throughout this project, major accomplishment and task are used 
consistently and are distinct from any other entities and attributes. 

B. ENTITY-RELATIONSHIP MODEL 

The ERD was drafted using the process outlined in Design of Enterprise Systems - 
Theory, Architecture, and Methods as a precursor to the relational diagram (Giachetti, 
2010). A complete draft of the ERD is located in Appendix B. Microsoft Visio 2010 was 
used as the tool to design the ERD. The program is user friendly. The most helpful 
feature was that when relationships were established between two entities, the primary 
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key would automatically migrant from the parent entity to the child entity as a foreign 
key. The most challenging feature was changing the crow’s foot notation. Namely once 
two entities were related and the relationship was determined to be incorrect, it was 
difficult to edit the relationship type. Later when entering the model in access, the 
difficulty editing the relationship type was often an indication that an associative entity 
was required. 

Although relationships, not order, are what drive an ERD, the ERD was drafted 
sequentially following the MRA process. The process started with the entity, Requestor, 
and finished with the entity, Option. While the ERD was drafted, nouns describing 
people, work or workload, and organization continued to be the focal points. In the 
following paragraphs, the ERD is discussed in greater detail and references are made to 
the ERD by entity. 

Entities that provide background information including the MRA request, the 
MRA team, and the MRA are shown in Figure 5. The entities, Requestor and 
MRARequest, and their respective attributes resemble the information found in USCG 
form 5310, The MRA Request. Not only is this information important, but the existence 
of these entities and attributes will contribute to transitioning the MRA request process 
from a manual to an electronic process. 
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Figure 5. Background Information including MRA, MRARequest, and 

MRATeam 


The ERD reflects sources of task and workload information. In this model, data is 
collected from reference documents including but not limited to Department of 
Homeland Security (DHS), USCG, and program documents, and via interviews and 
surveys as shown in Figure 6. Interview and survey information is found in a series of 
entities including Interview, InterviewQuestion, InterviewAnswer, Survey, 
SurveyQuestion, SurveyAnswer, and SurveyRespondent. Having a repository of 
interview and survey questions will alleviate the MRA team from drafting original 
questions for each MRA, yet provide the MRA team flexibility to tailor the interviews 
and surveys to different organizational elements. Having a repository of interview and 
survey answers will provide invaluable, historical perspective that may yield broader 
manpower requirement conclusions. 
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Figure 6. Sources of Task and Workload Information 


People information is found in the Position, Rate, and Rank entities as shown in 
Figure 7. The Position entity describes the required positions based on the MRA. Its 
primary key is PositionID. Position and PositionID are separate and distinct from 
positions on the Personnel Allowance List (PAL) and its respective position numbers. 
Within the entity, Position, there is a binary attribute, PresenceOnPAL. If a similar 
position is determined to be required as there already exists on the PAL, then the binary 
response recorded in PresenceOnPAL is yes. If the binary response is yes, then the 
PALPositionNumber will be recorded to facilitate a comparison between what is required 
and what exists. 
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Figure 7. People Information 


Work or workload information is found in the ERD in the Task, Competency, 
Workload, Major Accomplishment, Constraint, Assumption, and WorkWeekAvailability 
entities as shown in Figure 8. As you would expect, the Task entity appears to be the 
central entity of the ERD. Originally, the ERD was drafted with the workload attributes 
as part of the Task entity so it was previously even more dominate than it is now. 
Workload attributes were separated from the Task entity to make the spreadsheets more 
manageable. 
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Figure 8. Work and Workload Information 


Per SLMR manual, Volume III, competencies are supposed to be related to major 
accomplishments (Commandant, 2010a, p. 3-26). A relationship was drafted between the 
Task and Competency entities vice between the Major Accomplishment and Competency 
entities as shown in Figure 9. This was done because not ah task(s) rise to the level of a 
major accomplishment, but a particular competency or competencies may still be 
required to complete the task(s). Creating a relationship between the Task and 
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Competency entities will more thoroughly identify the competencies required to complete 
tasks and major accomplishments. 



Figure 9. Competency Relationship 


In the ERD, there is an Assumption entity and a GeneralAssumption entity. To 
alleviate any confusion between the two entities a short description follows. The 
Assumption entity applies to people and work or workload, and is related to the Position 
and Task entities as shown in Figure 8. The Assumption entity records published 
standards that influence the way and how much work is distributed to positions. The 
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GeneralAssumption entity provides background information, and is related to the MRA 
entity as shown in Figure 10. The GeneralAssumption entity influences the overall 
execution of the MRA. 
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Figure 10. GeneralAssumption Entity 


Organization information is found in the ERD in the OE, WorkCenter, and Option 
entities. OE is short for organizational element. An organizational element may be a unit 
or a portion of a unit. Work centers make up OEs, and OEs are collections of 
departments, divisions, branches, etc. The entity, WorkCenter is purposefully general. It 
should accommodate any OE’s organization. Any ambiguity should be resolved with the 
attribute, WorkCenterDescription. The OE and WorkCenter entities are connected 
through the Task entity as shown in Figure 11. 
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Figure 11. OE WorkCenter Relationship 


The Option entity catalogs each manpower alternative. In an earlier ERD draft, an 
MRD entity existed, however, it was deleted because it did not host much information. 
Instead, MRD was added as an attribute to the Option entity as shown in Figure 12. The 
MRD attribute is binary. One of the options will be the MRD, and a simple binary data 
point will communicate which option is the MRD clearly. 
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Figure 12. Option Entity 

C. RELATIONAL DATABASE 

Establishing an ERD ahead of the relational database made creating the relational 
database easy. The relational database was drafted in Microsoft Access 2013. The 
program is easy to use, however, not as user friendly as Microsoft Visio 2010. Creating 
tables and running queries, however, were particularly simple. 

The most inconvenient features of Microsoft Access 2013 were key migration, 
establishing relationships, and print margins. Unlike Microsoft Visio 2010, primary keys 
did not automatically migrate as foreign keys from parent to child entities. Foreign keys 
needed to be manually added in Microsoft Access 2013. Also relationships had to be 
deliberately made. A primary key needed to be specifically linked to another primary or 
foreign key for a relationship to be established, whereas in Microsoft Visio 2010, the 
relationship line only needed to be dragged into the entities in general for the linkage to 
be made. These shortcoming with Microsoft Access 2013 made the ERD particularly 
valuable as a guide to accurately building the relational database. The last inconvenience 
managed with Microsoft Access 2013 was that the print margins were not visible on the 
relationship tab or the Relationship Report, and a tool did not exist to zoom in or out of 
these screens which made viewing the relational database in its entirety impossible. 

The relational database was built in three steps: created tables or entities, 
established relationships, and inputted data. Creating the entities was easy. Establishing 
the relationships were more difficult. Several error messages populated the computer 
screen during the process. Most commonly, the error messages were resolved by editing 
the data type of the primary or foreign key, or by adding an associative entity. Primary 
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and foreign keys need to have the same data type in order to establish a relationship 
between them. Notable, Microsoft Visio 2010 has a much more extensive menu of data 
types than Microsoft Access 2013. Unlike the primary and foreign keys and the 
relationships, the data types do not replicate exactly from Microsoft Visio 2010 to 
Microsoft Access 2013. Adding an associative entity resolved specifically the 
indeterminate relationship error message. 

Data type selection was a little tedious. Early on, AutoNumber was used for many 
of the artificial primary keys. Two issues were discovered in doing this. First, Microsoft 
Access 2013 only permitted one attribute per entity to have an AutoNumber data type. 
This was problematic as primary keys migrant, and often migrated to entities that already 
had AutoNumber data type attributes. Next, AutoNumber generated a single, non-unique 
numbering scheme: one, two, three, four, etc. This was not ideal because if many 
attributes had an AutoNumber data type then their numbering scheme would be identical 
and eventually confusing when synthesizing data. Ultimately the Short Text data type 
was the default data type, because voluminous alphanumeric information was inputted. 
The Number data type did not allow any alpha characters. 

As my last step prior to testing, data was inputted. Data from the Regional Dive 
Locker Pacific and the WTGB 140’ (Bay) Class Icebreaking Harbor Tug MRAs was 
used. Some made-up information was also inputted. Specifically the MRA data helped to 
validate that the identification of entities and attributes was thorough. The compilation of 
data is not intended to yield any specific result, but merely exists to facilitate test and 
evaluation of the relational database. 

Inputting data to the relational database served as a premature evaluation. It 
helped me identify areas where data was lacking and redundancies. The datasheet view 
was easy to navigate, and observe where edits were required. For example in the 
Constraint entity, each type of constraint was listed as an attribute but during data entry 
edited to a single attribute, ConstraintType. 
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D. DESCRIPTION OF VERIFICATION AND VALIDATION 


The objective of this project was to build a data repository, and to be able to 
summarize the data within the repository in reports and spreadsheets similar to the 
products in MRA reports. The relational database was tested using queries. Specifically, 
the MFPU MRA Report was reviewed, and similar reports were successfully produced. 
On average, the relational database can produce approximately 70% of the spreadsheets 
and reports found in MRAs. A combination of real and fictitious data was used in testing, 
so the results reflected in the generated spreadsheets and reports below are fictitious. 

The MFPU MRA Report listed the project’s assumptions as shown in Figure 13. 
This product was replicated with simulated data as shown in Figure 14. Figure 14. 
specifically demonstrates the repository capability of the relational database in that it 
reflects all project assumptions entered in the relational database by MR AT P and OE 
name. 


6.1 Project Assumptions 

The following assumptions were integrated into the analysis: 

• The higher the degree of analytical rigor, the more accurate the MRD; the more accurate 
the MRD. the better the MRD helps Sponsors manage resources, requirements, and risk. 

• The MRA Sponsor will provide a Sponsor’s Representative that will be readily available 
to facilitate all aspects of the MRA. 

• The MRA Sponsor will provide extant data described in the Sponsor’s Guidebook and 
identified in the Alignment Meeting or by SMEs. 

• The MRA Team will have reasonable access to SMEs, APs, and other key personnel, and 
will coordinate requests, meetings, briefs, conferences, and interviews with the MRA 
Sponsor. 

• Manpower workload demand for an OE is determined by mission requirements, operating 
environment, asset configuration, and equipment, and is expressed as average man- 
hoursweek. 

• Budgetary constraints, allowances for personnel in a transient leave status, inadequately 
trained personnel, habitability constraints, and abnormal operational demands resulting 
from military contingencies and emergencies are excluded. In essence, the MFPU is 
fully funded, all MFPU staff are full-trained and fully-qualified when they arrive for the 
billet they are assigned and the MFPU will operate under normal circumstances. 

Figure 13. MFPU MRA Report Project Assumptions 
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OEName 

Bay Class Icebreaking HarborTug 

AssumptionDescription 

The technical estimates of time required to accomplish work, broken down intc 

MRA001 

Bay Class Icebreaking HarborTug 

Unless otherwise indictated, only work normally assigned and completed by W 

MRA 001 

Bay Class Icebreaking HarborTug 

All relevent extant data and information was presented to the MRD analysts. 

MRA001 

Bay Class Icebreaking HarborTug 

The WTGB world of work is determined by its mission requirements. 

MRA001 

Bay Class Icebreaking HarborTug 

WTGB missions will not change in the foreseeable future. 

MRA 002 

Regional Dive Locker Pacific 

The technical estimates of time required to accomplish work, broken down intc 

MRA002 

Regional Dive Locker Pacific 

Unless otherwise indictated, only work normally assigned and completed by W 

MRA002 

Regional Dive Locker Pacific 

All relevent extant data and information was presented to the MRD analysts. 

MRA 002 

Regional Dive Locker Pacific 

The WTGB world of work is determined by its mission requirements. 

MRA002 

Regional Dive Locker Pacific 

WTGB missions will not change in the foreseeable future. 

MRA003 

Maritime Force Protection Unit 

The technical estimates of time required to accomplish work, broken down intc 

MRA003 

Maritime Force Protection Unit 

Unless otherwise indictated, only work normally assigned and completed by W 

MRA003 

Maritime Force Protection Unit 

All relevent extant data and information was presented to the MRD analysts. 

MRA 003 

Maritime Force Protection Unit 

The WTGB world of work is determined by its mission requirements. 

MRA 003 

Maritime Force Protection Unit 

WTGB missions will not change in the foreseeable future. 


Figure 14. Relational Database Assumption Output 


Finished workload is computed using the equation, workload finished (WLp) = 
workload computed (WLc) x workload multiplier (WLm). These calculations are 
typically performed within the Work Matrix for an MRA. The relational database, 
however, has the capability to store all the required data and then with the application of 
code perform necessary mathematical computations. Although writing code was outside 
the scope of this project, all the required data is available in the relational database as 
shown in Figure 15. For the purposes of visual representation, WL F was manually 
calculated. 



WorkloadComputed - 

WorkloadMultiplier 

» WorkloadFinished » 


CTT 

1.13 

23.4 


1.99 

1.13 

2.2 


20.6 

1.13 

23.4 


11.3 

1.13 

12,8 


1.99 

1.13 

2.2 

* 




Figure 15. Relational Database Workload Finished Data 


The MFPU MRA Report summarized the competencies used in the MRA as 
shown in Figure 16. The summary was imitated with simulated data as shown in Figure 
17. 
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Competency 

Id 

Competency 

Type 

Competency 

Title 

Competency Description 

YNADM 

Personnel 

Administrative 

Specialist 

Demonstrates knowledge of USCG administrative 
policies, procedures, and correspondence. 

GM02 

Weapons 

Armorer 

The GM02 Armorer Competency will authorize 
members a higher degree of maintenance 
responsibility by allowing them to repair small arms 
beyond the operator level. 

SPCSVBCM 

Boat Ops 

BCM SPC SV 

BCM safely perform their duties under the 
supervision of a COXN. They stand helm, lookout, 
towing watches, and anchor watch. They also rig 
towing and mooring lines, act as the surface 
swimmer, administer first aid, and operate damage 
control equipment. They have knowledge of 
general boat operations and the local operating 
area. 

CRWSPC 

Boat Ops 

BCM SPC-LE 

Crewmembers safely perform their duties under 
the supervision of a coxswain. They stand helm, 
lookout, towing watches, and anchor watch. They 
also rig towing and mooring lines, act as the 
surface swimmer, administer first aid, and operate 
damage control equipment. They have knowledge 
of general boat operations and the local operating 
area. 


Figure 16. MFPU MRA Report Competency List 


CompetencyCode • 

CompetencyType - CompetencyTitle * CompetencyDescription 

Afloat Operations CMPLUS Maintenance 501753 CMPLUS Maintenance 

|i/VTGB 001 

WTGB_002 

Afloat Operations Team Coordination Training-Cutter OPS 500686 Team Coordination Training-Cut 

WTGB_003 

Afloat Operations ATON Deck Supervisor 230015 ATON Deck Supervisor 

WTGB_004 

Afloat Operations Minor Aids Maintenance 500622 Minor Aids Maintenance 




Figure 17. Relational Database Competency Output 


The capability to compare manpower requirements as determined by an MRA and 
current manning informs the drafting of options toward the end of an MRA. The MFPU 
MRA report made such a comparison as shown in Figure 18. The comparison was 
replicated with simulated data as shown in Figure 19. however, a binary attribute, 
PresenceOnPAL was engineered to communicate whether the position already existed on 
the PAL or if it represented a gap. If the position exists on the PAL, the position number 
is found adjacent to the binary attribute. 
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MFPU PAL versus MRD Comparison 


Org Element 

MFPU PAL 

BANGOR MRD 

Kings Bav 
MRD 


PAL Position Title 

Rank 

Q«y 

MRD Position 
Title 

Rank 

Qty 

Rank 

Q«> 

COMMAND 

COMMANDING 

OFFICER 

CDR 

l 

Commanding 

Officer 

CDR 

l 

CDR 

l 

EXECUTIVE 

OFFICER 

LCDR 

l 

Executive 

Officer 

LCDR 

l 

LCDR 

l 

SILVER BADGE 
CMD CHIEF 

POCM 

l 

Command 
Master Chief 

POCM 

l 

POCM 

l 


Figure 18. MFPU MRA Report PAL vs. MRD Comparison 


WorkCenterName 

- PositionID » 

WTGB - BM1 

PositionTitle 

Deck Division Head 

PresenceOnPAL 

0 

▼ PALPositionNumber » 

1234567 

Boat Division 

WTGB - BM2 

Assistant Navigator 

□ 


Boat Division 

WTGB-BM3 

Deck Division Lead Petty Officer 

0 

3456789 

Boat Division 

WTGB - BMC 

Operations Department Head/Navigator 

0 

4567891 

Boat Division 

WTGB - SA/SN 

Deck Division 

0 

5678912 


Figure 19. Relational Database PAL vs. MRA Comparison 


E. CHAPTER SUMMARY 

This evolution confirms that the implementation of a relational database would 
yield efficiency in manpower requirements determination. Critical in the development 
process is the draft of an ERD. The ERD is an invaluable guide to building the relational 
database. That said, test and evaluation of the relational database begins almost 
immediately. Microsoft Access 2013 sends error messages when establishing 
relationships, inputting data, and running queries, so the opportunity exists throughout 
development to continually improve the relational database. It is an iterative process. 
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IV. SUMMARY, CONCLUSIONS AND 
RECOMMENDATIONS 


A. SUMMARY 

The United States Coast Guard (USCG) executes 11 missions around the clock 
and the world, and in varying threat and weather conditions dictating an agile and 
responsive workforce. Therefore, determining manpower requirements and getting the 
right people, in the right places, at the right times, with the right skills is an ongoing and 
complex process. Too few or underqualified people may adversely impact safety, 
readiness, and mission execution. Too many or overqualified people may siphon funding 
from other priorities. 

The USCG and Navy processes for determining manpower requirements are 
similar, however, some fundamental differences exist. For example, the USCG has 
adopted many Navy processes as its own, yet has centralized the authority for shore 
manpower requirements determination unlike the Navy. Regardless of similarities and 
differences, there is benefit to the USCG and the Navy remaining appraised of the other 
service’s best practices and lessons learned. Exchange between the services will 
contribute to optimizing their respective manpower requirements determination 
processes. 

The intent of a Manpower Requirement Determination Automated Information 
System (MRD AIS) is to improve the accuracy of determining manpower requirements, 
alleviate time intensive manual processes, standardize manpower analysis, increase 
transparency, bolster adaptability, optimize manpower allocation, and identify alternative 
staffing solutions. The purpose of this study was to demonstrate the potential value in 
implementing a MRD AIS in the USCG. Modeling the factors that contribute to 
determining manpower requirements in an entity-relationship diagram (ERD), and 
subsequently testing via a relational database confirmed that implementing a similar 
model and database would yield efficiency in manpower requirements determination. 
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B. CONCLUSIONS AND RECOMMENDATIONS 


The primary research question is: 

What are the data requirements to determine Coast Guard manpower 
requirements? 

Conclusion: As a result of a thorough review of the USCG Staffing Logic and 
Manpower Requirements (SLMR) Manuals, Volumes I-IV; associated job aids and 
templates, and recent MRAs for the following organizational elements: Judge Advocate 
General (JAG) Program, Maritime Force Protection Unit (MFPU), Regional Dive Locker 
Pacific, and WTGB 140’ (Bay) Class Icebreaking Harbor Tug, a comprehensive list of 
entities, attributes, and their respective definitions was drafted. Nouns describing people, 
work or workload, and organization were the focal points to determine data requirements. 
This information is consolidated in the Data Dictionary located in Appendix A. 

Recommendation: The USCG Manpower Requirements Determination Division 
ought to commit to the full implementation of an MRD AIS. This type of tool, consistent 
with this project’s findings, will yield efficiencies associated with MRD. The potential 
implementation supports the nature of twenty-first century threats and fiscal challenges, 
getting the right people, to the right places, at the right times, with the right skills. The 
entities, attributes, and relationships identified in this research should be reviewed to 
either revise the MRD AIS delivered by the contractor or used as the foundation for a 
new MRD AIS. 

The secondary research question is: 

How does the Navy determine manpower requirements, and how does their 
process inform this research? 

Conclusion: The Navy uses site visits and Navy Manpower Requirements 
Systems (NMRS) to determine Fleet manpower requirements, and 34 individual, 
decentralized Budget Submitting Offices to determine manpower requirements for their 
respective programs. 
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The USCG and Navy processes for determining manpower requirements are 
similar in regard to workload measurement and Fleet manpower requirements 
determination. The greatest similarity is that the USCG and the Navy use NMRS to pair 
workload information, specifically workload hours, with occupational knowledge, skills, 
and abilities to quantify and qualify Fleet manpower requirements. NMRS produces a 
recommended manpower mix based on validated workload information. The USCG is 
able to use this Navy product, because the nature of work between the services is 
comparable. 

Recommendation: The USCG Manpower Requirements Determination Division 
should continue to leverage its relationship with the Navy Analysis Manpower Center 
(NAVMAC), and its use of NMRS. Currently, NMRS appears to be a most capable tool 
at the USCG’s disposal. Synergy between the USCG Manpower Requirements 
Determination Division and NAVMAC may contribute to optimizing both organizations’ 
MRD processes. 

C. FURTHER RESEARCH 

A team of students from acquisition, computer science, manpower, and systems 
engineering curriculums and USCG Headquarters subject matter experts should refine 
and advance the work completed within this project. Particular capabilities that should be 
added to this project’s database include code to perform mathematical computations and 
to yield summary data, work and workload distribution, and optimization capabilities. 
Interface with other USCG databases including the Abstract of Operations System, the 
Training Management Tool, the Aviation Logistics Management Information System, 
and Direct Access may also be helpful. It is possible, however, that an MRD AIS may 
alleviate the need for one or more of these existing databases. 

Another method to accelerate the USCG’s implementation of an MRD AIS is to 
conduct research that would determine how NMRS would need to be modified to also 
contribute to determining shore manpower requirements. Ultimately, a standardized 
MRD AIS that would determine Fleet and shore manpower requirements would yield 
efficiency. 
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APPENDIX A. DATA DICTIONARY 


Entity 

Definition 

Reference 

Contractor 

A person hired by the Coast Guard to contribute to the completion of an 
MRA. 


Attribute 

Definition 

Reference 

ContractorlD 

An alphanumeric code used to identify contractors. 


LastName 

The contractor's last name. 


FirstName 

The contractor's first name. 


ContractorOrganization 

The organization for which the contractor works. 


ContractorContactNumber 

The contractor's phone number. 


ContractorContactE-mail 

The contractor's e-mail address. 
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Entity 

Definition 

Reference 

MRATeamMember 

A coast guard member or contractor that works on one or more teams to 
accomplish MRA(s). 


Attribute 

Definition 

Reference 

MRATeamMemberlD 

An alphanumeric code used to identify MRA team members. 


MRATeamID 

An alphanumeric code used to identify MRA teams. 


MRAID 

An alphanumeric code used to identify MRAs. 


ContractorlD 

An alphanumeric code used to identify contractors. 


EMPLID 

A numeric code used to identify coast guard members. 


MRAPosition 

The roles filled by members of the MRA team e.g., requestor, project 
manager, analyst, etc. 
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Entity 

Definition 

Reference 

MRATeam 

The collection of Coast Guard members and contractors that work on 
respective MRAs. 


Attribute 

Definition 

Reference 

MRATeamID 

An alphanumeric code used to identify MRA teams. 


TeamName 

The name of the MRA team. 
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Definition 

Reference 


MRA is the manpower requirements analysis. 


Attribute 

Definition 

Reference 

MRAID 

An alphanumeric code used to identify MRAs. 


OEName 

The name of the organizational element. 


MRACategory 

An assignment given to an MRA request: A- directed, B - sponsor- 
contracted, C - periodic review, D - sponsor-requested, E - Modeling & 
simulation 

(Commandant, 2010a, p. 
2-4) 

MRAPriority 

A score yielded by the MRA Request Prioritization Decision Matrix that 
dictates the priority of an MRA within a category 

(Commandant, 2010a, 
pp. 2-5-2-6) 

MRA Level 

The level of analytical rigor applied to an MRA: Level 1 - Manpower 
Estimate Report, Level 2 - Workload Consolidation, Level 3 - Workload 
Validation, Level 4 - Workload Observation 

(Commandant, 2014, p. 
3.C.I.) 

Comments 

Amplifying information provided in regard to the MRA. 
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Entity Definition 

MRARequest Coast Guard form 5310 that initiates a MRA 


Attribute 

Definition 

Reference 

MRARequestID 

An alphanumeric code used to identify MRA requests. 


RequestDate 

The date the MRA request was submitted. 


OEName 

The name of the organizational element. 


OEType 

Organizational element type e.g. DCMS/DCO staff element, district staff, 
operational unit, etc. 

(Commandant, 2014, p. 
3-1-43) 

OEMRATrigger 

The specific reason(s) that prompted the need for the analysis. 

(Commandant, 2014, p. 
3-1-35) 

OEDateLastMRA 

The last date an MRA was completed. 


OESize 

The size of the organizational element. 


ImportanceToSponsor 

The importance to the sponsor e.g., essential to mission readiness, aligns 
with strategic goals, etc. 

(Commandant, 2014, p. 
3-1-44) 

MRAID 

An alphanumeric code used to identify MRAs. 


RequestorOfficeName 

The office in which the requestor works. 


Comments 

Amplifying information provided in regard to the MRA. 



Reference 
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Entity 

Definition 

Reference 

Requestor 

The senior member that initiated the MRA request. 


Attribute 

Definition 

Reference 

RequestorOfficeName 

The office in which the requestor works. 


PrimaryPocRank 

The primary point of contact's rank. 


PrimaryLastName 

The primary point of contact's last name. 


PrimaryFirstName 

The primary point of contact's first name. 


SecondaryPocRank 

The secondary point of contact's rank. 


SecondaryPocLastName 

The secondary point of contact's last name. 


SecondaryPocFirstName 

The secondary point of contact's first name. 
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Entity 

Definition 

Reference 

OE 

The su bject of the M RA. 


Attribute 

Definition 

Reference 

OEName 

The name of the organizational element. 


HQUnit 

Binary indication of whether or not the organizational element is a Coast 
Guard headquarters' unit. 


Fieldllnit 

Binary indication of whether or not the organizational element is a Coast 
Guard field unit. 
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Entity 

Definition 

Reference 

GeneralAssumption 

General assumptions provide direction in regard to how the MRA should 
be executed. 


Entity 

Definition 

Reference 

GenAssumpID 

An alphanumeric code used to identify general assumptions. 


MRAID 

An alphanumeric code used to identify MRAs. 


GenAssumpDescription 

General assumption description. 


DateAdded 

The date on which the assumption was added. 


DateModified 

The date on which the assumption was modified. 


Comments 

Amplifying information provided in regard to the general assumption. 
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Entity 

Definition 

Reference 

MDMBusinessRule 

MDM Business Rules direct how the overall MRA should be executed. 


Attribute 

Definition 

Reference 

RuleSet 

Numeric code used to identify the MDM rule set. 


MRAID 

An alphanumeric code used to identify MRAs. 


RuleDescription 

MDM rule description. 
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Entity 

Definition 

Reference 

WorkCenter 

A portion of an organizational element e.g., department, division, office, 
branch, etc. 


Attribute 

Definition 

Reference 

WorkCenterName 

The work center's name. 


WorkCenterDescription 

A description of the work center. 
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Entity 

Definition 

Reference 

Workload 

The activity of a body or mind which can be measured against standards 
in time, quantity or quality including but not limited to operation of 
equipment, watches, military duties, military assemblies, maintenance, 
administration, support, utility tasks, evolutions, training, supervision, 
job-related conversations, etc. 

(Commandant, 2014, p. 
Glossary) 

Attribute 

Definition 

Reference 

TaskID 

The alphanumeric code used to identify the task. 


WorkloadID 

The alphanumeric code used to identify the workload. 


Frequency 

Data field used to indicate the rate of occurrence for a work item. 

(Commandant, 2010a, p. 
3-16) 

TaskMonth 

Data field used to indicate the month or months in which the OE 
accomplishes the work (for quarterly, semi-annual, or annual work). This 
provides the ability to conduct a cyclical work/workload analysis during 
the modeling and simulation phase. 

(Commandant, 2010a, p. 
3-17) 

TaskCount 

Data field used to record the maximum number of times a work item is 
accomplished during a specified period. The count may be multiplied to 
include the number of persons involved. It may also be fractionalized for 
work with annual frequencies exceeding every 4 years for example .2 
count with a frequency of annual would be every five years. 

(Commandant, 2010a, p. 
3-17) 

WorkloadRaw 

The knowledge base task mean. 

(Commandant, 2010a, p. 
3-50) 

WorkloadFactor 

A workload factor is an index or unit of measure that is consistently 
relatable to the work required to accomplish a specifically defined 
responsibility; e.g., the number of officers ably serviced by an assignment 
officer, or the number of personnel records ably serviced by a Yeoman. 

(Commandant, 2010a, p. 
5-8) 
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WorkloadComputed 

OE workload computed is the workload for each task based on the 
workload minutes per week times the work count for each task 
performed at the OE. 

(Commandant, 2010a, p. 
3-52) 

WorkloadMultipler 

The workload multiplier is applied to workload computations to account 
for various process slowing events. 

(Commandant, 2010a, p. 
3-52) 

WorkloadFinished 

Workload finished is the workload with appropriately applied PF&D 
multiplier expressed in minutes per week for each OE task. 

(Commandant, 2010a, p. 
3-56) 

DurationOptimistic 

Data field that represents the most efficient time required to complete a 
single work item. Work Duration is recorded using selectable responses 
such as 5-10 minutes, 10-15 minutes, etc. If available selectable 
responses cannot adequately explain the duration of the work item the 
analyst should record the reason for this in the analyst notes column of 
the work matrix. 

(Commandant, 2010a, p. 
3-17) 

DurationProbable 

Data field that represents the most common time required to complete a 
single work item. Work Duration is recorded using selectable responses 
such as 5-10 minutes, 10-15 minutes, etc. If available selectable 
responses cannot adequately explain the duration of the work item the 
analyst should record the reason for this in the analyst notes column of 
the work matrix. 

(Commandant, 2010a, p. 
3-17) 

DurationPessimistic 

Data field that represents the least efficient time required to complete a 
single work item. Work Duration is recorded using selectable responses 
such as 5-10 minutes, 10-15 minutes, etc. If available selectable 
responses cannot adequately explain the duration of the work item the 
analyst should record the reason for this in the analyst notes column of 
the work matrix. 

(Commandant, 2010a, p. 
3-17) 
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Entity 

Definition 

Reference 

Task 

Task and work item are synonymous, but task is used to remain 
consistent with the Accomplishment Based Curriculum Development 
system. Basic identification of work accomplished or services 
performed. Tasks should be easy to identify, convenient for obtaining 
productive count, and usable for scheduling, planning, and costing. 

(Commandant, 2014, p. 
Glossary) 

Attribute 

Definition 

Reference 

TaskID 

The alphanumeric code used to identify the task. 


TaskTitle 

A descriptive title of the work item 

(Commandant, 2010a, p. 
3-13) 

TaskReference 

A unique alphanumeric reference for each work item 

(Commandant, 2010a, p. 
3-13) 

TaskDescription 

A more detailed description of the work item 

(Commandant, 2010a, p. 
3-13) 

TaskSponsor 

The program manager for the specific work item being described for 
example CG-OOH for Civil Rights related work items 

(Commandant, 2010a, p. 
3-13) 

TaskOESubstructure 

A descriptive field that points to specific work center within the OE in 
which the work item is performed. 

(Commandant, 2010a, p. 
3-13) 

TaskLaborTypeCharacteristics 

Information about the work item that may indicate the use of one 
type of manpower over another for example the work item is military 
essential and therefore requires military personnel to complete it. 

(Commandant, 2010a, p. 
3-13) 

ReferenceClass 

Work is categorized by the source from which it was discovered, as 
either documented (work base on official doctrine, directives, or 
other authoritative, written sources of information) or undocumented 
(work based on unofficial or informal practices, policies or rules that 
must be adjudicated during the MRA process in order to be included 
in the manpower determinants model). 

(Commandant, 2010a, p. 
3-14) 
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TaskType 

Used to classify work/workload as either direct (work conducted to 
accomplish the OE's mission(s), function(s) and goal(s)) or indirect 
(work that does not directly support an OE's assigned mission(s), 
function(s), and goal(s), but is performed in order to manage 
organizational, personnel, and capital assets) 

(Commandant, 2010a, p. 
3-14) 

TaskClass 

Used to group work items into designated categories for example SAR 
(search and rescue - direct work), SML (supervision, management, and 
leadership - indirect work), COL (collateral duties - indirect work), TRA 
(training - indirect work), and HRM (human resource management - 
direct work). 

(Commandant, 2010a, p. 
3-14) 

TaskSsic 

A broad function category that describes the work item in terms of 
the most applicable standard subject identification code (SSIC) for the 
specific type of referenced work. 

(Commandant, 2010a, p. 
3-14) 

TaskFunction 

A more detailed description of documented work items, using the 
noun title of the SSIC. 

(Commandant, 2010a, p. 
3-14) 

TaskManpowerType 

Identifies the particular labor source linked to a work item (military 
active/reserve, civilian, contractor, or volunteer) that generally has a 
common set of workforce availability and constraints. 

(Commandant, 2010a, p. 
3-15) 

TaskEnvironment 

Identifies the primary place that the work item is performed for 
example at sea or inport, on or off watch, etc. 

(Commandant, 2010a, p. 
3-15) 

OEName 

The name of the organizational element. 


MAID 

The alphanumeric code used to identify the major accomplishment. 
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Entity 

Definition 

Reference 

Position 

A designated placeholder as indicated in the personnel allowance list or 
determined to be necessary per an MRA. A position represents all jobs, duties, 
skills, responsibilities, and supervisory relationships assigned to an employee. 

(Commandant, 2014, p. 
Glossary) 

Attribute 

Definition 

Reference 

PositionID 

The alphanumeric code used to identify the position. 


PositionTitle 

The title of the position. 


PresenceOnPAL 

Binary indication of whether or not the position is on the personnel allowance 
list. 


PALPositionNumber 

The position number on the personnel allowance list. 


DateAdded 

The date on which the position was added. 


Date Modified 

The date on which the position was modified. 


Comments 

Amplifying information provided in regard to a position. 
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Definition 

Reference 


A particular position achieved within a hierarchy. 


Attribute 

Definition 

Reference 

RankAbbreviation 

The rank's abbreviation. 


RankName 

The name of a rank. 
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Definition 

Reference 

Rate 

The specialty of an enlisted member. 


Attribute 

Definition 

Reference 

RateAbbreviation 

The rate's abbreviation. 


RateName 

The name of a rate. 
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Entity 

Definition 

Reference 

WorkWeekAvailability 

Coast Guard human capital management processes use work week 
availability as planning factors help define manpower needed to 
accomplish identified missions and associated work requirements for 
various organizational elements. Standard workweeks are guidelines for 
sustained personnel use and should not be viewed as binding on a 
command's ability to manage its unit workforce. 

(Commandant, 2014, p. 
3-1-21) 

Attribute 

Definition 

Reference 

PositionID 

The alphanumeric code used to identify a position. 


AvailabilityHrsWk 

The number of hours per week each labor source is available to dedicate 
to productive work activities. 

(Commandant, 2010a, p. 
3-24) 

Planning Factor 

A conversion factor applied to workload raw for each task. 

(Commandant, 2010a, p. 
3-50) 

Manpower Required 

The number and types of positions required to successfully accomplish 
all of the work assigned to the OE. 

(Commandant, 2010a, p. 
4-3) 

Overall Unit Work 

Utilization 

Range at which a position requirement or set of requirements in an OE 
may be either not fully utilized, likely to be optimally utilized, at or near 
maximum load and exceed target load, or exceed maximum load and are 
unlikely to meet workload demands. 

(Commandant, 2010a, p. 
4-7) 
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Entity 

Definition 

Reference 

Assumption 

Assumptions are characteristics about an OE, its mission and workers that 
must be assumed to provide a starting point from which to determine the 
appropriate manning. 

(Commandant, 2010a, p. 
3-25) 

Attribute 

Definition 

Reference 

AssumptionID 

The alphanumeric code used identify an assumption. 


AssumptionDescription 

The description of the assumption. 


DateAdded 

The date on which the assumption was added. 


Date Modified 

The date on which the assumption was modified. 


Comments 

Amplifying information provided in regard to an assumption. 
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Entity 

Definition 

Reference 

Constraint 

Business rules that must be taken into account when identifying 
work requirements or assigning workload to a particular labor force 
in the MRA process. Represent statutory or policy level limitations 
on the amount of work certain Coast Guard personnel can do, or 
the type of workers assigned to do the work. Factors act as filters 
through which final manpower options are modeled. 

(Commandant, 
2014, p. Glossary) 

Attribute 

Definition 

Reference 

ConstraintID 

The alphanumeric code used to identify the constraint. 


ConstraintType 

Work designation, workforce type, work location, operational 
status, specialty/rate type, rank/paygrade type, cutter 
employment standards, watchstanding duty requirements, or 
crew endurance factors. 

(Commandant, 
2010a, pp. 3-19 - 
3-24) 

ConstraintDescription 

The description of the constraint. 


DateAdded 

The date on which the constraint was added. 


DateModified 

The date on which the constraint was modified. 


Comments 

Amplifying information provided in regard to a constraint. 
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Entity 

Definition 

Reference 

MajorAccomplishment 

Output of behavior that has direct value to the goals of the job and the 
organization. 

(Commandant, 2014, p. 
Glossary) 

Attribute 

Definition 

Reference 

MAID 

The alphanumeric code used to identify the major accomplishment. 


MAName 

The name of the major accomplishment. 


MADescription 

The description of the major accomplishment. 
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Entity 

Definition 

Reference 

Competency 

Knowledge, skills, abilities, personal characteristics, qualifications, 
training, education, licenses/certifications, and prior assignments 
needed to perform work to a predetermined, measurable standard. 

(Commandant, 2014, p. 
Glossary) 

Attribute 

Definition 

Reference 

CompetencyCode 

An alphanumeric code up to eight characters long that 
uniquely identifies a competency in DA. This code is established when 
the competency is created in DA. Users will only see this code when 
creating ad hoc competency queries. 

(Commandant, 2005, p. 
2-3) 

CompetencyTitle 

The title of the competency. 


CompetencyDescription 

An alphanumeric acronym or abbreviation up to 10 characters long 
that provides enough information to allow a person to identify a 
competency uniquely. Used for code validation when creating ad hoc 
competency queries. 

(Commandant, 2005, p. 
2-3) 

CompetencyType 

The assigned functional or mission area where the 
requirement of the competency is concentrated; i.e.. Afloat 

Operations; Aviation; Command, Control, Communications, Computers 
and Information Technology (C4IT). Competencies may be assigned 
multiple types. 

(Commandant, 2005, p. 
2-3) 
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CompetencyCategory 

The classification of a competency establishing the kind of 
competency; knowledge, skill, ability, or other (behavior). 

(Commandant, 2005, p. 
2-3) 

CompetencyProficiencyScale 

The proficiency rating scale, displayed as 

"Rating" in DA is used to establish the level of competence. This scale 
applies to both persons and positions. For the individual member, it 
describes the proficiency level the person has achieved. For a position, 
it describes the level of proficiency needed to be successful in the 
position. The associated levels may vary with each competency. Levels 
typically include: None, Little, Good, Very Good, and Expert. 

(Commandant, 2005, p. 
2-3) 

CompetencyDefinition 

The complete description of the competency. The 

competency definition is written in a specific manner, describing what 

the holder of the competency can do. 

(Commandant, 2005, p. 
2-3) 

CompetencyRequirements 

The complete listing of all qualification 

requirements (schools. Personnel Qualification Standard [PQS], time, 
prerequisite competencies, etc.), and any restriction on who the 
competency may be assigned to (military only, civilian, enlisted. 
Auxiliary, or pay grade). 

(Commandant, 2005, p. 
2-3) 

Competencylmportance 

This field is used to establish the desired/required need for the 
competency for an assigned position. This characteristic is only used 
when a competency is assigned to a position. See Table 2-1 for 
importance descriptions. 

(Commandant, 2005, p. 
2-3) 

DateAdded 

The date on which the competency was added. 


DateModified 

The date on which the competency was modified. 


Comments 

Amplifying information provided in regard to a competency. 
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Entity 

Definition 

Reference 

Option 

A result from the modeling effort. 


Attribute 

Definition 

Reference 

OptionID 

The alphanumeric code used to identify an option. 


OptionDescription 

The description of the option. 


MRD 

Binary indication of whether or not a particular option is the MRD. 


DateAdded 

The date on which the option was added. 


DateModified 

The date on which the option was modified. 


Comments 

Amplifying information in regard to an option. 
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Entity _ 

Allowance 


Attribute _ 

AllowancelD 

AllowanceType 

Allowance 

WorkFacility 

location) 

WorkCategory 

WorkCondition 

environment) 

DateAdded 

DateModified 

Comments 


(work 


(work 


Definition 

A standard applied to workload to adjust for factors including working 
conditions, physical & mental exertion requirements, etc. 


Definition 

An alphanumeric code used to identify an allowance. 

The specific type of personal, fatigue, or delay consideration. 

The name of the specific allowance. 

The performance environment, for example boat, cutter, shore facility 

Work activity or series of work actions for example evolutions, general 

administration, maintenance, training, watchstanding 

General physical environment in which the work is performed for 

example hanger, moored, office, underway 

The date on which the allowance was added. 

The date on which the allowance was modified. 

Amplifying information provided in regard to an allowance. 


Reference 

(Commandant, 2010a, p. 
3-52) 


Reference 


MRA PF&D Template 


MRA PF&D Template 


MRA PF&D Template 
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Entity 

Definition 

Reference 

ReferenceDocument 

A document that directs or provides amplifying information in regard to 
an organizational element's work or workload. 


Attribute 

Definition 

Reference 

Title 

The title of the reference document. 


DhsDODSsic 

If applicable, the standard subject identification code used to identify a 
reference document. 


PublicationDate 

The date the reference document was published. 


PublicationOrganization 

The organization that published the reference document. 
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Definition 

Reference 


A series of questions that facilitate work measurement. 


Attribute 

Definition 

Reference 

SurveylD 

An alphanumeric code used to identify the survey. 


SurveyDate 

The date the survey was conducted. 


SurveyAudience 

A description of to whom the survey was distributed. 



70 






Entity 

Definition 

Reference 

SurveyQuestion 

A question asked on the survey. 


Attribute 

Definition 

Reference 

SurveyQuestionID 

An alphanumeric code used to identify the survey question. 


SurveyQuestionDescription 

A representation of the question asked on the survey. 


Survey ID 

An alphanumeric code used to identify the survey. 
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Entity 

Definition 

Reference 

SurveyAnswer 

The answer provided to a survey question. 


Attribute 

Definition 

Reference 

SurveyQuestionID 

An alphanumeric code used to identify the survey question. 


SurveyAnswerlD 

An alphanumeric code used to identify the survey answer. 


SurveyAnswer 

The response provided to the survey question. 


RespondentN umber 

A numeric code assigned to survey respondents other than an employee 
ID. This code facilitates anonymity of survey respondents, but allows 
summary statistics to be tied to survey respondent demographics 
including rank and rate. 
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Entity 

Definition 

Reference 

SurveyRespondent 

A person that responds to a survey. 


Attribute 

Definition 

Reference 

RespondentN umber 

A numeric code assigned to survey respondents other than an employee 
ID. This code facilitates anonymity of survey respondents, but allows 
summary statistics to be tied to survey respondent demographics 
including rank and rate. 


RespondentRate 

The rate of the survey respondent. 


RespondentRank 

The rank of the survey respondent. 
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Entity 

Definition 

Reference 

Interview 

A verbal exchange between a member at the organizational element 
being analyzed and an MRA team member to facilitate work 
measurement. 


Attribute 

Definition 

Reference 

InterviewlD 

An alphanumeric code used to identify the interview. 


InterviewDate 

The date the interview was conducted. 


EMPLID 

A numeric code used to identify coast guard members. 
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Entity 

Definition 

Reference 

InterviewQuestion 

A question asked during the interview. 


Attribute 

Definition 

Reference 

InterviewQuestionID 

An alphanumeric code used to identify the interview question. 


InterviewQuestionDescription 

A representation of the question that was asked during the interview. 


InterviewlD 

An alphanumeric code used to identify the interview. 
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Entity 

Definition 

Reference 

InterviewAnswer 

The answer to an interview question. 


Attribute 

Definition 

Reference 

InterviewQuestionID 

An alphanumeric code used to identify the interview question. 


InterviewAnswerlD 

An alphanumeric code used to identify the interview answer. 


InterviewAnswer 

The response to the interview question. 
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